1. Field of the Invention
The present invention generally relates to a communications system, and more specifically to a system and method for synchronizing nodes in a mobile communications system.
2. Background of the Related Art
Recently, the International Mobile Telecommunication (IMT)-2000 standard has been introduced as one of the Future Public Land Mobile Telecommunication Systems (FPLMTS). Through this standard, the communication of voice, data or other types of information is made possible with one mobile terminal anywhere and anytime around the world. In terms of the IMT-2000 network, Internet data transmission is made to mobile terminals (MTs) through a packet switching device for Global System for Mobile Communications (GSM) packet service (i.e., an SGSN) and through a gateway inter-working with the packet network (i.e., a GGSN).
In order to provide a General Packet Radio Service (GPRS) for subscribers, serving GPRS Support Nodes (SGSNs) record location information of relevant mobile terminals and conduct subscriber authentication and the matching with the Gateway GPRS Support Node (GGSN). The GGSN assigns IP addresses to the mobile terminal requesting packet service, transfers packet data coming from the SGSN to the outside packet network such as the Internet, and transfers packet data coming from the outside to the relevant mobile phone. For the inter-working of SGSNs and a GGSN having the above-described features, the SGSNs and the GGSN need to be synchronized.
FIG. 1 illustrates a synchronizing system of SGSNs and a GGSN in the prior art. This system comprises network time protocol (NTP) server 10 which distributes a timestamp to the entire network, a GGSN 20, and a number of SGSNs 30 which receive the timestamp from the NTP server 10. The GGSN and SGSNs are synchronized by receiving the timestamp distributed by the NTP server.
The GGSN 20 comprises a GGSN-System Management Processor (G-SMP) 21 and a GGSN-Interface (G-Interface) 23. The G-SMP 21 manages the repair and maintenance of the switching device at the GGSN side. Also, the G-SMP comprises a GGSN-NTP Client (G-NTP Client) 22, which transmits NTP request packets to the NTP server 10 and receives NTP acknowledgement packets from the NTP server, thus receiving the timestamp.
The G-Interface serves as an interface between the NTP server and the GGSN through the Transmission Control Protocol/Internet Protocol (TCP/IP) communication. The SGSN comprises an SGSN-System Management Processor (S-SMP) 31 and an SGSN-Interface (S-Interface) 33. The S-SMP manages the repair and maintenance of the switching device at the SGSN side. Also, the S-SMP comprises an SGSN-NTP Client (S-NTP Client) 32, which transmits NTP request packets to the NTP server 10 and receives NTP acknowledgement packets from the NTP server thus receiving the timestamp. The S-Interface serves as an interface between the NTP server and the SGSN through the TCP/IP communication. The G-Interface and S-Interface may be an Ethernet Port or Fast Ethernet Subscriber Front Assembly (FESFA) interface.
FIG. 2 shows the structure of the NTP request packet and the NTP acknowledgement packet according to the prior art.
FIG. 3 shows a prior-art method for synchronizing SGSNs and a GGSN. First, when an NTP Client starts operation, it creates a User Datagram Protocol (UDP) socket in order to use the Ethernet port connected to the SMP. In other words, at the time of initial operation, the G-NTP Client 22 of the GGSN 20 and the S-NTP Client 32 of the SGSN 30 create UDP sockets to use the G-Interface 23 and the S-Interface 33 connected to the G-SMP 21 and S-SMP 31, respectively (S301).
Then, the G-NTP Client and the S-NTP Client set up NTP request packets of the NTP packet format as illustrated in FIG. 2 (S302). When setting up NTP request packets, the NTP Client specifies the mode of the NTP packet as “Client Mode” and specifies the destination port and the source port with different numbers. For example, the destination port may be No. 123 and the source port may be No. 3000. The reason why the Client Mode is manifested is to be able to receive a timestamp from the NTP server 10. The destination port and the source port are specified with different numbers in order to operate the NTP packet either as client mode or as server mode.
Thereafter, the G-NTP Client 22 and the S-NTP Client 32 transmit the above-mentioned NTP request packets to the NTP server 10 through the UDP sockets (S303). Then, the NTP server receives the NTP request packets, sets up NTP acknowledgement packets to distribute timestamp to the G-NTP Client 22 and the S-NTP Client 32, and transmits the NTP acknowledgement packets to the G-NTP Client 22 and the S-NTP Client 32.
The G-NTP Client and the S-NTP Client receives NTP acknowledgement packets from the NTP server (S304) and reviews the received NTP acknowledgement packets to determine the validity of the received timestamp (S305). In other words, upon receiving NTP acknowledgement packets from the NTP server, the G-NTP Client and the S-NTP Client conduct procedures to set up a timestamp pursuant to the procedures recommended in “RFC 959.” For this purpose, version and mode, etc., of the NTP acknowledgement packets are reviewed to determine whether the versions are the same and whether the mode is the server mode.
After said review process (S305), if it is determined that the received NTP acknowledgement packets are not valid (i.e., if the versions are not identical or if the mode is not the server mode), the G-NTP Client 22 and the S-NTP Client 32 wait for the polling time (S306) and returns to the step of NTP request packet setup (S302).
On the other hand, after the review process (S305), if it is determined that the received NTP acknowledgement packets are valid (i.e., the versions are identical and the mode is the server mode), the G-NTP Client 22 and the S-NTP Client 32 set up the time of the SMP using the timestamp of the NTP acknowledgement packets. Specifically, the time of the G-SMP 21 and the time of the S-SMP 31 are set up upon adding local time differences to the timestamp of the NTP acknowledgement packets, respectively. In this manner, the time of GGSN 20 and the time of SGSN 30 are set up (S307). The above time conversion of adding a relevant local time difference is conducted because the timestamp of the NTP acknowledgement packet is a standard time which is the same regardless of the relevant local time difference.
The G-NTP Client 22 and the S-NTP Client 32 determine whether the time of the G-SMP 21 and the time of the S-SMP 31 have been synchronized with the time of the NTP server 10 (S308).
Upon the above determination (S308), if the synchronization has been accomplished, the G-NTP Client 22 and the S-NTP Client 32 are synchronized with the time of the NTP server 10, respectively. Accordingly, the G-NTP Client 22 and the S-NTP Client 32 are synchronized with each other. Thus, the synchronization step is completed.
On the other hand, if the above determination process (S308) shows that the synchronization has not been accomplished, the G-NTP Client 22 and the S-NTP Client 32 wait for the polling time (S306) and then return to the step of NTP request packet set up (S302).
In the above-described system for synchronizing SGSNs and a GGSN of the prior art, if the NTP server experiences a malfunction, the GGSN and the SGSNs must operate on their own time frames. If the NTP server's malfunction continues, the time variation between the GGSN and the SGSNs becomes greater and greater. Thus, the SGSNs and the GGSN may not operate in a synchronized manner.
Further, if the GGSN experiences a malfunction the SGSNs and the GGSN would not be synchronized, because the GGSN would not be able to maintain the synchronization with the NTP server while the SGSNs would be synchronized with the NTP server.
Also, if any specific SGSN among multiple SGSNs experiences a malfunction, the other SGSNs, the GGSN and the NTP server would be synchronized but the SGSN experiencing the malfunction would not be synchronized with the other nodes (i.e., the other SGSNs, the GGSN and the NTP server). Consequently, there would be serious problems in the inter-operation of the SGSNs and the GGSN for time-related functions such as authentication and packet exchange.